Currently, a network functions virtualization (NFV) technology attracts more and more attentions. On Oct. 23, 2012, 13 operators released an NFV white paper, and announced setup of a network functions virtualization specification working group (NFV ISG) in the European Telecommunication Standards Institute (ETSI).
The operators set up the NFV ISG with a view to defining operator requirements for network functions virtualization and related technical reports, wishing to implement some network functions on universal high-performance servers, switches, and storage devices. This requires that network functions should be implemented in a software form, run on hardware of a universal server, and be migrated, instantiated, and deployed in different positions in a network according to requirements. In addition, installation of new devices is not required. Separation of software from hardware can be implemented on various network devices such as servers, routers, storage devices, and switches by using the NFV technology.
In a conventional NFV management and orchestration (MANO) system, due to a layered NFV system architecture, NFV faults may occur at different layers in the network, for example, infrastructure faults at a network functions virtualization infrastructure (NFVI) layer, virtualized network function (VNF) software faults, and network faults. The infrastructure faults may include hardware faults (for example, a hard disk input/output fault, a server power outage, and a port fault), virtual machine (VM) faults, and the like.
In the prior art, an NFV fault needs to be reported to a fault correlation entity and a fault decision entity first. The fault is rectified only after the fault correlation entity analyzes a root cause of the fault and the fault decision entity makes a fault processing decision. Therefore, from detection of the NFV fault to fault rectification, there is an analysis and processing delay, so that the fault decision entity can make a correct decision. However, an NFVI fault is different from a VNF fault. The VNF fault may be caused by another fault. The infrastructure fault itself is a root-cause fault, and does not need a root cause analysis and decision. Therefore, in a method for processing an infrastructure fault in the prior art, a processing delay is long.